There
is also a way for the service to present a set of credentials to the
client. This is required to support mutual authentication and message
protection. Also, when transport security is specified, the service’s
credentials might be needed to provide the required functionality.
In the absence of any
information to indicate differently, the Windows credentials for the
service are used, assuming that the binding requires mutual
authentication because of transport security or message security. If
you desire a different set of credentials for the service, you must specify them in the serviceCredentials element within the behaviors
section. For example, the following segment from a configuration file
tells the service to use the certificate with a subject name of
UpdateKey in the local certificate store:
<behaviors>
<serviceBehaviors>
<behavior name="serviceBehavior" >
<serviceCredentials>
<serviceCertificate findValue="RPKey"
storeLocation="LocalMachine" storeName="My"
x509FindType="FindBySubjectName" />
</serviceCredentials>
</behavior>
</serviceBehaviors>
</behaviors>
If you plan on using an
alternative set of credentials, it is important to be aware of some of
the potential ramifications. For example, in the preceding segment, a
certificate is specified for the service’s credentials. If the client
needs to encrypt the message sent to the service, the public key
portion of this certificate must be available to the client. This can
be provided either out of band (by providing the public key information
to install on the client) or it can be negotiated with an initial
handshake. The choice you make is specified in the negotiateServiceCredential attribute in the message element of the binding, as shown in bold in the following example:
<wsHttpBinding>
<binding name="wsHttp">
<security mode="Message">
<message clientCredentialType="Certificate"
negotiateServiceCredential="true" />
</security>
</binding>
</wsHttpBinding>
Again, as a caveat, the
protocols used to negotiate are not interoperable in all situations.
For Windows credentials, the SPNEGO protocol is used. For UserName, Certificate,
or anonymous credentials, the TLSNEGO protocol is used. These protocols
request the correct encryption token dynamically before any messages
are exchanged.
Alternatively, when the
automatic negotiation of service credentials is disabled, there are
also some limitations. If Windows client credentials are to be used, a
Kerberos domain must be available. This domain retrieves the encryption
token. For other client credential types, the service credentials can
be hard-coded, as shown in bold in the following segment:
<behavior name="Client">
<clientCredentials supportInteractive="false">
<clientCertificate storeLocation="CurrentUser"
storeName="TrustedPeople" x509FindType="FindBySubjectName"
findValue="UpdateKey"/>
<serviceCertificate>
<defaultCertificate storeLocation="CurrentUser"
storeName="TrustedPeople x509FindType="FindBySubjectName"
findValue="localhost"/>
</serviceCertificate>
</clientCredentials>
</behavior>
Alternatively,
an encoded version of the public portion of the service’s certificate
can be supplied in the definition of the endpoint. For example, the
following segment from a configuration file is generated by the svcutil
utility:
<client>
<endpoint address="http://localhost:8000/UpdateService"
binding="wsHttpBinding" contract="UpdateService"
name="WSHttpBinding_UpdateService">
<identity>
<certificate encodedValue="AwAAAAEAAAAUAAAA...oVbTtOA=="/>
</identity>
</endpoint>
</client>